A traditional architecture which includes telephony devices and computers is illustrated in FIG. 1. In this traditional architecture, first and second user computers 10, 50 are connected to the Internet 40. First and second user telephones 20, 60 would be connected to the Public Switched Telephone Network (PSTN) 30. Any telephone conversations conducted by the users would initially pass through the PSTN. The operators of the PSTN might route calls through the Internet, but the interface to the actual user telephones would still pass thought the PSTN.
Telemarketers and others who must rapidly place a series of telephone calls have used software which enables a user to place telephone calls using telephone numbers appearing in lists on their computers. Typically, the user would have a list of telephone numbers that appear on the user's computer screen. The user would highlight or select one of the telephone numbers to place a telephone call to the selected number.
In the context of a telemarketer, the user telephone could take the form of a device or expansion card which is installed in the user's computer. One or more separate telephone lines (each having a different telephone number) would be connected to the device, and a headset with a microphone and a speaker element would also be connected to the device. Software running on the user's computer is then used to cause the device to place telephone calls to selected telephone numbers over the telephone lines connected to the device. When a call is connected, the user would be able to talk and hear the call using the headset.
In some embodiments, the computer and the associated calling software are capable of communicating directly with the PSTN, either through a telephone line or via an Internet connection, so the software can instruct the PSTN to place telephone calls.
A method of rapidly placing calls using the architecture illustrated in FIG. 1 would start when User 1 highlights and selects a telephone number assigned to User 2's telephone 60. In some embodiments, the software running on User 1's computer 10 would send signals to the PSTN 30 (either directly or via the Internet) to instruct the PSTN to place a first telephone call to User 1's telephone device 20 over a first telephone line 22, and to place a second call to User 2's telephone 60 over telephone line 62. The signals sent from User 1's computer would also instruct the PSTN to bridge the first and second calls. User 1's telephone would then ring, and User 1 would pick up immediately. User 1 would then hear the call being connected to User 2's telephone 60. If User 2 answers the telephone call, User 1 could begin talking In other embodiments, the software running on User 1's computer would cause User 1's telephone device to directly call User 2's telephone.
When the call is finished, both User 1 and User 2 would hang up, and User 1 could then highlight and select the next telephone number on his list and the process would be repeated.
In the system described above, when calls are being bridged by the PSTN to connect User 1 and User 2, it is necessary for two telephone calls to be placed over two lines, and for the PSTN to bridge the two calls. Placing two calls and bridging the calls in this fashion is considerably more expensive than simply placing a single telephone call from User 1's telephone device 20 to User 2's telephone 60. However, the increased cost is worthwhile because it enables User 1 to rapidly and accurately place calls to multiple telephone numbers stored on an electronic list.
Also, if User 2 does not answer the call, but an answering machine or answering service does answer the call, User 1 could leave a message. Alternatively, the software running on User 1's computer might be capable of causing a pre-recorded message to be recorded on User 2's answering service while User 1 moves on to another call.
To accomplish this, the software would make User 1's computer play the audio message over the first line 22 connected to User 2's telephone 60. The software would also switch User 1's headset or audio interface over to a second line 24. The software would then place a call to User 3. As explained above, this could be accomplished by instructing the PSTN to place a third call to User 1's telephone device 20 over the second line 24, and to place a fourth call to User 3's telephone 70 over line 72. The PSTN would then bridge the third and fourth calls. Or, the software could cause User 1's telephone 20 to directly dial User 3's telephone 70.
When calls are being bridged by the PSTN to connect User 1 with other parties, and User 1 moves on to a new call four telephone lines would be in use simultaneously. The first and second lines 22 and 62 would be used to cause the audio message to be played to User 2's answering service while the third and fourth lines 24 and 72 would be used to allow User 1 to place a call to User 3's telephone. While this enables User 1 to make the next call without wasting time leaving a message for User 2, it means that four lines will be in use, and that two bridges must be maintained. Here again, this involves considerable expense. But the time savings for User 1 make the expense worthwhile.
The description provided above explains one known system for allowing a user to place telephone calls using existing computer and telephone systems. In addition, there are various existing computer and telephony systems that provide voice services to users. These voice services can be speech recognition and touchtone enabled. Examples of such services include voice mail, voice activated dialing, customer care services, and the provision of access to Internet content via telephone.
One common example of a system that provides voice services is an Interactive Voice Response (IVR) system. In prior art systems, a user would typically use a telephone to call in to a central computer system which provides voice services via an IVR system. The IVR system deployed on the central computer system would then launch voice services, for instance by playing an audio clip containing a menu of choices to the user via the telephone line connection. The user could then make a selection by speaking a response. The spoken response would be received at the central computer system via the telephone line connection, and the central computer system would interpret the spoken response using speech recognition techniques. Based on the user's response, the IVR system would then continue to perform application logic to take further action. The further action could involve playing another menu of choices to the user over the telephone line, obtaining and playing information to the user, connecting the user to a third party or a live operator, or any of a wide range of other actions.
The ability to provide voice services has been quite limited by the nature of the systems that provide such services. In the known systems that provide voice services using relatively complex speech recognition processing, the voice applications are performed on high end computing devices located at a central location. Voice Application processing requires a high end centralized computer system because these systems are provisioned to support many simultaneous users.
Because complex voice application processing must be provided using a high end computer system at a central location, and because users are almost never co-located with the high end computer system, a user is almost always connected to the central computer system via a telephone call. The call could be made using a typical telephone or cell phone over the PSTN, or the call might be placed via a VoIP-type (Skype, SIP) connection. Regardless, the user must establish a dedicated, persistent voice connection to the central computer system to access the voice services.
The prior art centralized voice services platforms, which depend on a telephony infrastructure for connection to users, are highly inflexible from a deployment standpoint. The configurations of hardware and software are all concentrated on a small number of high end servers. These configurations are technically complex and hard to monitor, manage, and change as business conditions dictate. Furthermore, the deployment of existing IVR system architectures, and the subsequent provisioning of users and voice applications to them, requires extensive configuration management that is often performed manually. Also, changes in the configuration or deployment of IVR services within extant IVR architectures often require a full or partial suspension of service during any reconfiguration or deployment effort.
Further, cost structures and provisioning algorithms that provision the capabilities of such a centralized voice services platform make it virtually impossible to ensure that a caller can always access the system when the system is under heavy usage. If the system were configured with such a large number of telephone line ports that all potential callers would always be connected to access contrasting types of voice services, with different and overlapping peak utilization hours, the cost of maintaining all the hardware and software elements would be prohibitive. Instead, such centralized voice services platforms are configured with a reasonable number of telephone ports that result in a cost-effective operating structure. The operator of the system must accept that callers may sometimes be refused access. Also, system users must accept that they will not receive an “always on” service.
Prior art centralized voice services platforms also tend to be “operator-centric.” In other words, multiple different service providers provide call-in voice services platforms, and each service provider usually maintains their own separate platform. Thus, if a user has called in to a first company's voice services platform, he will not likely be able to access the voice services of a second company's platform during the same call. In order to access the second company's voice services platform, the user must terminate his call to the first company, and then place a new call to the second company's platform. Thus, obtaining access to multiple different IVR systems offered by different companies is not convenient.
In addition to the above-described drawbacks of the current architecture, the shared nature of the servers in a centralized voice services platform limits the ability of the system to provide personalized voice applications to individual users. Similarly, the architecture of prior art IVR systems limit personalization even for groups of users. Because of these factors, the prior art systems have limitations on their ability to dynamically account for individual user preferences or dynamically personalize actual voice applications on the fly. This is so because it becomes very hard for a centralized system to correlate the user with their access devices and environment, to thereby optimize a voice application that is tuned specifically for an individual user. Further, most centralized systems simply lack user-specific data.
Prior art voice services platforms also had security issues. In many instances, it was difficult to verify the identity of a caller. If the voice services platform was configured to give the user confidential information, or the ability to transfer or spend money, security becomes an important consideration.
Typically, when a call is received at the voice services platform, the only information the voice services platform has about the call is a caller ID number. Unfortunately, the caller ID number can be falsified. Thus, even that small amount of information could not be used as a reliable means of identifying the caller. For these reasons, callers attempting to access sensitive information or services were usually asked to provide identifying data that could be compared to a database of security information. While this helps, it still does not guarantee that the caller is the intended user, since the identifying data could be provided by anybody.